NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/2754

Internet Message Format | 1996-08-05 | 8.8 KB

Path: munnari.OZ.AU!metro!metro!news
From: [e-mail] (Accolyte)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Demo/game to OS frien
Date: 5 Feb 1996 11:44:42 GMT
Organization: Information Services, The University of Sydney, NSW, Australia
Distribution: inet
Message-ID: <[e-mail]>
References: <4e8h9j$[e-mail]><4e8pk2$[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
NNTP-Posting-Host: dialup46.wr.com.au
X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*


(I've combined two messages into one here to save space)
>>For compatibility one might consider using the system interrupt routines
>>as an *option* to the user, but taking over the interrupts should always
>>be available for those who want speed.
>
> Unless we're getting thousands of interrupts per second (which
> indicates we're probably using the wrong algorithm), no-one will
> notice the difference.  Oops, yes they will --- it makes the
> difference between work/crash on some configs.

It can make a big difference. Try running a mod-player before you
start certain demos that use the system interrupts. They go out of
frame and look terrible.



<snip>
>>> emulators from the same time period, such as the KGB one and the
>>> Italian one, were slightly faster than mine because they killed the OS
>>> and used copper tricks for the display. However they died an early
>>> death because they didn't work with "weird" configs like accelerators
>>> or A1200s.
>>
>>That's only because they made silly mistakes.
>
>Agreed.  They made the silly mistake of killing the OS right from the
>start.

Wait a sec, lets not jump the gun here. Killing the OS isn't a deadly
sin - it can add to the performance of a game. The problem is not having
an option to leave the system running.



<snip>
> Well, yes, emulators are different from games, just as games are
> different from each other.  IMO, hardly any emulators or games, if any
> at all, need to kill the OS.
>
> I can think of only one possibly valid reason for killing the OS.
> That is, the game bangs the custom hardware so fast to achieve the
> desired effect that there is no time for interrupts or context
> switches.  A game using dynamic HAM mode could be an example.  Of
> course, such a game would be extremely hardware dependent, and I can't
> think of a single game with such stringent requirements.

But if it means increased performance, it's worthwhile. As I said,
there can always be an option to keep the system running, for people
who like things like that.










>>Diamond Caves:  Too slow, and plays nowhere near as well as BaldersGrove

> Could it be the high-res interlace mode that slows Diamond Caves down?
> In any case, direct bitmap access is possible without killing the OS
> and Diamond Caves probably doesn't have an option for that.  I wonder
> whether BaldersGrove works at all on my system.

Nah, It's not the screenmode that's slowing it down, Diamond Caves only
uses an interlace screen for the title. (at least the way I had it playing)
I have no idea whether BaldersGrove works on your system. It is fairly well
written though. What is your system? It multitasks btw.



>> And I don't like Diamond Caves. First of all it opens an interlace
>> screen with no option to use anything else. What's this? No support
>> for people without multisyncs?
>
> Interlace works on 15kHz monitors around here.  Or are you saying you
> don't like the flicker?  Whatever the problem, it sounds like it is
> easily fixed without killing the OS.

Sorry, yes it's the flicker I don't like. It's acceptable with viewing
pictures etc, but for a menu, and places where you have numerous horizontal
lines it's just unbearable. Of course it can be fixed without killing the
OS, but it's silly not to have been thought of in a game supposedly breaking
out against the norm and supporting many different hardware configs.



>>Gloom Deluxe:   Point. Although it requires a much faster system to run
>>                acceptably. The stock 1200 routines are not system ones.
>
> Gloom Deluxe would be faster on an A1200 if it didn't kill the OS and
> if it used QBlit() for c2p.

How using QBlit() ever be faster that killing the OS and hitting hardware
on a 1200? I mean, you can still do async blitting with the hardware only.




> BTW, another great OS game is the classic old F18 Interceptor.
> Clearly it doesn't kill the OS because my network server works in the
> background.  In fact, I can't even tell when someone accesses my hard
> disk while I'm playing unless I look at the disk light.

Hmm, I think we more or less agree here. I have nothing against supporting
the OS. It's the people who say "use 100% OS routines" that I disagree
with. I wonder if F18 Interceptor uses some hw hitting, or if it's 100% OS.




>>Spectrum Emul:  Not a game :)
>
> So what if it's not a game.  It's 10000 games, many of which are
> better than ones in this list (arguably).

Hehe.. sure, but I still think it doesn't quite count in a list of
OS friendly games ;)  Utils should *definately* have a multitasking
option - they're much more often used with other programs than games
are.



>>Colonization:   Shocking code, and this in terribly slow, even for OS calls
>
> So how does killing the OS improve shocking code?

It doesn't, but shocking code kind of exludes it from being in a list
of good games in the first place. :)



>>DuneII:         Could be much faster
>>Angband:        If it's what I'm thinking of (moria clone?) then that's
>>                on par with the ol' text adventures in terms of system
>>                requirements :)
>
> And people write text adventures and disk mags that kill the OS  :-(

Text adventures, yeah that's a fair point. But you should understand that
with diskmags, the programmers are usually working for zilch profit and
have little inspiration to make it compatible with 100% of the systems
out there (although some do it anyway).



>> F18Interceptor: I can't remember this, but I'm sure it could've been much
>>                 faster/better.
>
> F18 Interceptor was written when A500s were the norm and it's still a
> classic, fast flight simulator.  I can run my network server in the
> background and I can't tell when someone accesses my hard disk unless
> I look at the disk light.

<thinks back> Still not sure.. <shrug>. Didn't it have disk based
protection or something (btw)?



>> Poing:          I admit, this is a downright trendy/addictive game :)
>                  But it's not overly complex is it?
>
> It would have to be incredibly complex before I would consider killing
> the OS.  Far too many coders decide to kill the OS from the start.
>
> IMHO all the above games are better than you make out.  On the other
> hand, none of them are perfect.  Some use only high-level OS calls,
> hence they work with gfx-cards but are relatively slow on stock
> A1200s.  This problem can be worked around without killing the OS.
> Indeed, all the games above could almost certainly all be improved
> without killing the OS.

Yes that's true.. that reminds me (for who-knows what reason) of something
that sucks about OS compliant software. More specifically, badly written
OS compliant software. I refer to OctaMED 3, (which is in other respects
*excellent* so please don't get me wrong Teijo :) ) - it allocates all the
audio channels when it starts, and frees them when it stops. How the hell
can I play a mod in the background, or search through my HD with a
directory utility for the right sound? I can't, because OctaMED has taken
over the audio channels, and all the other software refuses to play
anything if they're allocated. An option to ignore the channels being
allocated would be a great idea, just for those cases where other software
might not be written correctly. (And that in turn reminds me.. Poing hits
the audio hardware.. it that bad? :) )

BTW, I know OctaMED has been updated recently, but I can't stand the new
"OS style compliant" interface. The original one was perfect in my
opinion <sigh>




>> I think the trend is that the ONLY OS programmed games that will run
>> acceptably are the simple ones, and the ones designed for graphics
>> cards only. Where does that leave the people who don't have/want a
>> graphics card?
>
> To work with all gfx cards, a game must use high-level OS calls.  If
> that's too slow on a particular chipset then the game can allocate and
> bang within OS rules.  A good game would give the user both options.

Okay I agree.. is there anyone here who's willing to do both though?

I think another problem could be the luke-warm response programmers are
getting from people owning high-end machines. I don't mean anything
personal, but looking at the messages directed at Team17 lately,
and some of the comments in this newsgroup, it's less than helpful.